home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940003.txt < prev    next >
Internet Message Format  |  1994-11-13  |  8KB
  1. Date: Fri,  7 Jan 94 04:30:01 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #3
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Fri,  7 Jan 94       Volume 94 : Issue    3
  11.  
  12. Today's Topics:
  13.                            AMPR.org Domain
  14.            Extended KISS and SMACK specifications? (4 msgs)
  15.                         JNOS and Turbo C++ 3.0
  16.                      Problem compiling KA9Q nos..
  17.                                  test
  18.  
  19. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  20. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  21. Problems you can't solve otherwise to brian@ucsd.edu.
  22.  
  23. Archives of past issues of the TCP-Group Digest are available
  24. (by FTP only) from UCSD.Edu in directory "mailarchives".
  25.  
  26. We trust that readers are intelligent enough to realize that all text
  27. herein consists of personal comments and does not represent the official
  28. policies or positions of any party.  Your mileage may vary.  So there.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: Thu, 6 Jan 1994 11:10:56 -0600 (CST)
  32. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  33. Subject: AMPR.org Domain
  34. To: tcp-group@ucsd.edu
  35.  
  36. Over the holidays I made a few additions to the domain and
  37. then downloaded the file to see how all my entries took.
  38.  
  39. While my changes took as desired, I was surprised by the
  40. number of errors in there!  Rather than search for them
  41. all, I just changes the obvious errors.  The most
  42. significant number of errors was leaving the ',' off the
  43. end of a non-ampr.org domain.  Some people used ampr.org
  44. in their entry and never used a '.' and thus were known
  45. as:
  46.  
  47.     jimbob.ampr.org.ampr.org
  48.  
  49. after "ampr.org" is added to everything without a dot.
  50. Most cases were in the MX record though, and by leaving
  51. a '.' off the end of a "fully qualified domain name"
  52. results in:
  53.  
  54.     jimbob-state.edu.ampr.org
  55.  
  56. Not really what you wanted is it...
  57.  
  58. Anyway, you might take a look at the result and see if
  59. yours is fixed now :-)
  60. -- 
  61. Steve
  62.  
  63. ------------------------------
  64.  
  65. Date: Thu, 6 Jan 1994 14:38:11 +0200 (EET)
  66. From: mea@mea.cc.utu.fi ("Matti E. Aarnio [OH1MQK]")
  67. Subject: Extended KISS and SMACK specifications?
  68. To: louie@uunet.uu.net (Louis A. Mamakos)
  69.  
  70. > > My PK-88 supports "Extended KISS". This appears to include checksums,
  71. > > reporting of the transmission of a packet, and polling of the TNC by the
  72. > > host.
  73. > 
  74. > Wow.  Is this all a good thing?
  75. > 
  76. > KISS = "Keep It Simple, Stupid"
  77.  
  78.   Yes.  Lack of checksums on KISS in between TNC and the computer
  79. has been shown to be a problem on some cases (loaded computer,
  80. multiple TNCs, ..)   While it improves the interface in between
  81. the TNC, and the computer, it still is very KISS in deed.
  82. Alternative would be to hack automatic interaction with various
  83. types of TNCs -- and running TCP/IP would be next to impossible..
  84.  
  85.   I think Phil Karn had something to do with that E-KISS protocol,
  86. or was it just that he has said what things are missing missing from
  87. the original specs ?
  88.  
  89. > louie
  90. > wa3ymh
  91.  
  92.     /Matti Aarnio    <mea@utu.fi> oh1mqk
  93.  
  94. ------------------------------
  95.  
  96. Date: Thu, 6 Jan 1994 09:57:47 -0800 (PST)
  97. From: Lyndon Nerenberg <lyndon@unbc.edu>
  98. Subject: Extended KISS and SMACK specifications? 
  99. To: "Louis A. Mamakos" <louie@uunet.uu.net>
  100.  
  101. On Wed, 5 Jan 1994, Louis A. Mamakos wrote:
  102.  
  103. > > My PK-88 supports "Extended KISS". This appears to include checksums,
  104. > > reporting of the transmission of a packet, and polling of the TNC by the
  105. > > host.
  106.  
  107. > Wow.  Is this all a good thing?
  108.  
  109. Yes. There is no excuse for not having a data integrety check between the 
  110. TNC and computer, especially in light of the (IBM) PC's ability to drop 
  111. characters.
  112.  
  113. I'm not sure what's meant by "polling" here, however something else 
  114. that's sorely needed is the ability for the TNC to notify the PC that a 
  115. packet has been sent over the air. This let's the PC start the retransmit 
  116. timer when the packet is sent on the air, rather than when the PC sends 
  117. to the TNC.
  118.  
  119. > KISS = "Keep It Simple, Stupid"
  120.  
  121. You want to keep the protocol broken just to maintain backwards 
  122. compatibility with the name? Foo!
  123.  
  124. --lyndon
  125.  
  126. ------------------------------
  127.  
  128. Date: Thu, 06 Jan 1994 17:32:04 -0500
  129. From: "Louis A. Mamakos" <louie@uunet.uu.net>
  130. Subject: Extended KISS and SMACK specifications? 
  131. To: Lyndon Nerenberg <lyndon@unbc.edu>
  132.  
  133. [I wrote..] > > Wow.  Is this all a good thing?
  134.  
  135. > Yes. There is no excuse for not having a data integrety check between the 
  136. > TNC and computer, especially in light of the (IBM) PC's ability to drop 
  137. > characters.
  138.  
  139. Sure, there's a great excuse.  KISS was supposed to be SIMPLE and EASY
  140. to implement on hardware that couldn't support a direct connection to
  141. the link-layer hardware.
  142.  
  143. > I'm not sure what's meant by "polling" here, however something else 
  144. > that's sorely needed is the ability for the TNC to notify the PC that a 
  145. > packet has been sent over the air. This let's the PC start the retransmit 
  146. > timer when the packet is sent on the air, rather than when the PC sends 
  147. > to the TNC.
  148.  
  149. Once you begin to add all this complexity, I contend that you'd be
  150. better off spending the effort writing a driver to support a more
  151. tightly-coupled hardware interface.
  152.  
  153. > > KISS = "Keep It Simple, Stupid"
  154. > 
  155. > You want to keep the protocol broken just to maintain backwards 
  156. > compatibility with the name? Foo!
  157.  
  158. No, the point as I understand it was to build a simple, non-broken,
  159. low-capability protocol.  I claim that attempting to unreasonably
  160. extend the KISS protocol breaks it.
  161.  
  162. louie
  163. wa3ymh
  164.  
  165. ------------------------------
  166.  
  167. Date: Thu, 6 Jan 1994 14:59:05 -0800 (PST)
  168. From: Lyndon Nerenberg <lyndon@unbc.edu>
  169. Subject: Extended KISS and SMACK specifications? 
  170. To: "Louis A. Mamakos" <louie@uunet.uu.net>
  171.  
  172. > > Yes. There is no excuse for not having a data integrety check between the 
  173. > > TNC and computer, especially in light of the (IBM) PC's ability to drop 
  174. > > characters.
  175.  
  176. > Sure, there's a great excuse.  KISS was supposed to be SIMPLE and EASY
  177. > to implement on hardware that couldn't support a direct connection to
  178. > the link-layer hardware.
  179.  
  180. Do you work for Sun? This sounds like their reasoning for turning off NFS 
  181. UDP checksums: dump the error checking so we can make the benchmarks look 
  182. better.
  183.  
  184. KISS = Keep It Stupid, Simple. 
  185.  
  186. Not!
  187.  
  188. ------------------------------
  189.  
  190. Date: Thu, 06 Jan 94 15:47:00 PST
  191. From: Martin Lines <mlines@sni.co.uk>
  192. Subject: JNOS and Turbo C++ 3.0
  193. To: "'nos-bbs'" <nos-bbs@hydra.carleton.ca>, tcp-group <tcp-group@ucsd.edu>
  194.  
  195. Has anyone achieved the impossible and got  a vaguely stable version of JNOS 
  196.  
  197. using the TC++ 3.0 compiler.
  198.  
  199. Mine crashes instantly with Invalid pointers in cmdintr.
  200.  
  201. Here' s hoping!
  202.  
  203. Martin - G1SEO
  204.  
  205. ------------------------------
  206.  
  207. Date: Thu, 06 Jan 94 10:14:15 EST
  208. From: RLM@MAINE.maine.edu (Robert L. Metcalf NV1A)
  209. Subject: Problem compiling KA9Q nos..
  210. To: tcp-group@ucsd.edu (TCP folx)
  211.  
  212. Hi..
  213.  
  214. I have a question about NOS...  I FTP'd what I think is the latest
  215. version of KA9Q NOS from ucsd.edu:
  216.  
  217.  -r--r--r--  1 257        939922 Jul  1  1993 rcsdsrc.zip
  218.  
  219. I have un-RCS'd the files and compiled and assembled all
  220. of the pieces (with make), but make has a problem when it
  221. comes time to link everything together.  There are a
  222. lot of undefined labels, etc..  I think my problem is that I am using
  223. Turbo C++ version 3.0 and an old version of TASM (v1.01)..  I think the
  224. .OBJ files created by my TASM are not compatible with the new compiler
  225. tools.(?)  Is there a way to fix this?
  226.  
  227. Are the .OBJ files for the new assembly source available via FTP?
  228.  
  229. Thanks!
  230. Rob NV1A
  231. rlm@maine.maine.edu
  232.  
  233. ------------------------------
  234.  
  235. Date: Thu, 06 Jan 94 13:03:00 PST
  236. From: tijc02!SMROUTER!LEROJX%ALPH1%SIAMAIL%MSROUTER@uunet.UU.NET
  237. Subject: test
  238. To: tcp-group@ucsd.edu
  239.  
  240. TO:smrouter/tcp-group@ucsd.edu
  241. test
  242.  
  243. ------------------------------
  244.  
  245. End of TCP-Group Digest V94 #3
  246. ******************************
  247.